Computer program product for selectively reducing bandwidth of real-time video data

ABSTRACT

Method, apparatus and computer program product are disclosed for selectively reducing the bandwidth of real-time video data for transmission on a bus having varying bandwidth, while minimizing perceptible loss of picture quality. After detecting an overflow condition within a buffer coupled to a bus, video data to be written to the buffer is discarded until a prior pending request for transmission of a pending block of video data from the buffer is granted and begun. After beginning the transmitting, the discarding of data is discontinued and new video data is written into the buffer. A next bus request is made for transmission of all remaining data in the buffer stored prior to detecting the overflow condition. The amount of discarded data in the line is monitored and used to determine an address for a new block of data stored after the discontinuity in the line of video data. Temporal redundancies between frames of a video image is employed to fill in the discontinuity in the line of video data by using correspondingly positioned data in a corresponding line of a prior frame or field.

CROSS-REFERENCE TO RELATEE APPLICATION

This application comprises a divisional patent application from commonlyassigned, patent application Ser. No. 08/872,573, filed Jun. 10, 1997,now U.S. Pat. No. 5,986,714, which is hereby incorporated herein byreference in its entirety.

TECHNICAL FIELD

This invention relates to video data processing and transfer, and moreparticularly to a method, apparatus and computer program product forselectively reducing the bandwidth of real-time video data fortransmission on a bus having varying bandwidth, without perceptible lossof picture quality.

BACKGROUND OF INVENTION

The moving picture experts group (MPEG) MPEG-2 standard is acompression/decompression standard for interactive video applications.The standard describes an encoding method that results in substantialbandwidth reduction by a subjective lossy compression followed by alossless compression. The encoded, compressed digital data issubsequently decompressed and decoded in an MPEG-2 compliant decoder.

The MPEG-2 standard specifies a very high compression technique thatachieves compression not achievable with intraframe coding alone, whilepreserving the random access advantages of pure intraframe coding. Thecombination of frequency domain intraframe encoding andinterpolative/predictive interframe encoding of the MPEG-2 standardresults in a balance between intraframe encoding and interframeencoding.

The MPEG-2 standard exploits temporal redundancy for motion compensatedinterpolative and predictive encoding. That is, the assumption is madethat "locally" the current picture can be modeled as a translation ofthe picture at a previous and/or future time. "Locally" implies that theamplitude and direction of the displacement are not the same everywherein the picture.

The MPEG-2 standard further specifies predictive and interpolativeinterframe encoding and frequency domain intraframe encoding. It hasblock based motion compensation for the reduction of temporal redundancyand discrete cosine transform based compression for the reduction ofspatial redundancy. Under MPEG-2, motion compensation is achieved bypredictive coding, interpolative coding, and variable length codedmotion vectors. The information relative to motion is based on a 16×16array of pixels and is transmitted with the spatial information. It iscompressed with variable length codes, such as Huffman codes.

Video decoding in accordance with the MPEG-2 standard is described ingreater detailed in commonly assigned U.S. Pat. No. 5,576,765, entitled"Video Decoder," which is hereby incorporated herein in its entirety.

One aspect of current video decoding techniques is apparent from thefollowing detailed example. An International Business MachinesCorporation MPEGCD1M decoder is designed for a PC platform and itsassociated applications. This decoder provides a glueless interface tothe PCI local bus, with multiple direct memory access ports for highperformance data transfer capability. The decoder also provides for thecapability to transmit decoded (i.e., decompressed) video image data tosystem memory or directly to a graphic accelerator's frame buffer. Theprior destination is useful for video capture, while the latterdestination is employed for display to the PC monitor.

The decompressed video data can have an approximate data rate of 27MB/sec., and although a 33 MHz PCI bus has a theoretical bandwidth of132 MB/sec., sufficient bandwidth may not be consistently available totransmit this video data. The PCI local bus does not guarantee that acertain bandwidth will always be available. Obviously, this might be aproblem for the transmission of real-time video data without perceptibleloss of picture quality.

The present invention addresses the above-noted issue, which cangenerally be stated as a desire to process decompressed, real-time videodata for transmission on a non-real-time medium with minimal loss ofperceptible picture quality.

DISCLOSURE OF THE INVENTION

Briefly summarized, the invention comprises in one aspect a method forprocessing a line of video data for transmission across a bus, the lineof video data being temporarily written to a buffer. The buffer iscoupled to the bus for reading of data in blocks from the buffer to thebus. The method includes: detecting an overflow condition within thebuffer; upon detecting the overflow condition, discarding data from theline of video data being temporarily written to the buffer; upongranting of a pending request for transmission of a pending block ofvideo data from the buffer, transmitting the pending block of video datafrom the buffer to the bus, the pending request being pending prior tothe detecting of the overflow condition, and upon beginning thetransmitting, discontinuing the discarding of data; and providing atleast one next bus request for transmission of at least one next blockof video data from the buffer to the bus, the at least one next block ofvideo data comprising all remaining video data in the buffer storedtherein prior to the discarding of data.

In another aspect, apparatus for processing a line of video data isdisclosed. The apparatus includes a first-in first-out (FIFO) buffer,and a bus coupled to the FIFO buffer. The apparatus further includes acontroller coupled to the FIFO buffer and to the bus for controlling theprocessing of the line of video data through the FIFO buffer fortransmission across the bus. The controller comprises means fordetecting an overflow condition within the buffer and means fordiscarding data from the line of video data being temporarily written tothe buffer after detecting the overflow condition. The controllerfurther includes means for transmitting a pending block of video datafrom the buffer upon granting of a pending request for transmission ofthe pending block of video data from the buffer. The pending request ispending prior to detecting of the overflow condition. Upon beginning thetransmitting, means for discontinuing the discarding of data isprovided, and thereafter for providing at least one next bus request fortransmission of at least one next block of video data from the buffer tothe bus. The at least one next block of video data comprises allremaining video data in the buffer stored prior to detecting theoverflow condition.

In still another aspect, the invention comprises computer programproduct for processing a line of video data for transmission across thebus. The line of video data is temporarily written to a buffer, which iscoupled to the bus for the reading of data in blocks from the buffer tothe bus. The computer program product includes a computer usable mediumhaving computer readable program code means embodied in the medium forcausing a selective reduction in bandwidth of the line of video data.The computer program product has: computer readable program code meansfor causing the computer to detect an overflow condition within thebuffer; computer readable program code means for causing the computer todiscard data from the line of video data being temporarily written tothe buffer upon detecting the overflow condition; computer readableprogram code means for causing the computer to transmit a pending blockof video data from the buffer upon granting of a pending request fortransmission of the pending block of video data from the buffer, thepending request being pending prior to detecting the overflow condition,and upon beginning the transmitting, to discontinue the discarding ofdata from the line of video data being temporarily written to thebuffer; and computer readable program code means for causing thecomputer to provide at least one next bus request for transmission of atleast one next block of video data from the buffer to the bus, the atleast one next block of video data comprising all remaining video datain the buffer stored therein prior to detecting the overflow condition.

To restate, presented herein is an approach for transmitting real-timevideo data on a non-real-time medium with minimal loss of perceptiblepicture quality. The video data transfer apparatus takes advantage ofthe temporal redundancies between frames in the MPEG video system bydropping pixel data at random spatial locations corresponding to wheninsufficient bus bandwidth is available, and relying on the previouslyspatially located pixel data to replace the lost data. The effectiveresult is transmission of a video image with "holes" or discontinuitieswhere data was not transmitted. These holes are replaced by thepreviously spatially located pixel data. Thus, in accordance with theinvention, the video processing system is able to tolerate greateroccurrence of insufficient bus bandwidth without degrading perceptiblepicture quality. Processing in accordance with this invention can beperformed in place of or in addition to conventional techniques forreducing bandwidth of decompressed video data.

BRIEF DESCRIPTION OF DRAWINGS

The above-described objects, advantages and features of the presentinvention, as well as others, will be more readily understood from thefollowing detailed description of certain preferred embodiments of theinvention, when considered in conjunction with the accompanying drawingsin which:

FIG. 1 shows a video data transfer apparatus to employ the dataprocessing and transfer approach of the present invention;

FIG. 2 is a representation of a video frame having multiple horizontalvideo lines to be processed in accordance with the present invention;

FIGS. 3a & 3b represent a horizontal video line and normal data packetprocessing thereof, respectively;

FIGS. 4a & 4b depict a horizontal video line, and data packet processingthereof pursuant to overflow recovery processing in accordance with thepresent invention, respectively;

FIG. 5 is a flowchart of video data processing and transfer under normalconditions in accordance with the present invention;

FIG. 6 is a flowchart of one embodiment of overflow recovery processingin accordance with the present invention;

FIGS. 7a, 7b & 7c depict a horizontal video line, transfer of video datapackets, and buffer fullness, respectively, under normal processingconditions; and

FIGS. 8a, 8b & 8c depict a horizontal video line, transmission of datapackets where bus bandwidth is less than the pixel data rate coming intothe buffer, and buffer fullness, respectively, for overflow recoveryprocessing conditions addressed in accordance with the presentinvention.

BEST MODE FOR CARRYING OUT THE INVENTION

Several techniques are possible for use in reducing the bandwidth ofdecompressed video data for output on a bus having limited bandwidth.One technique would be to simply drop pixels in a predefined location toscale down the video. This is only effective for small scaling factorssince video quality typically degrades to unacceptable limits whenscaled down more than one-half times. Degrading of the video isespecially noticed when it is scaled back up to restore the video image.Another technique is to perform a linear interpolation of adjacentpixels. However, this also proves to be a poor bandwidth limiting filterwhen scaled below one-half of the original image.

A further approach, comprising the present invention, is to takeadvantage of the temporal redundancies between frames. This approach canbe performed in place of or in addition to the above-noted bandwidthlimiting techniques.

Generally stated, a principal premise of the present invention is todrop pixel data in random spatial locations when insufficient busbandwidth is available to receive the video data. The frame buffer,which is a destination of video data being sent across the bus, isconstantly being overwritten with the video image data from the nextframe. When a pixel is dropped, the previously spatially located pixelremains in place of the lost data. Since pixels are dropped randomly inaccordance with the present invention, it is unlikely that the "old"pixel data is significantly different than the pixel data which waslost. This is because of the temporal redundant nature of video. Theeffective result is a transmitted video image with "holes" where datawas not transmitted. The number and size of these holes is inverselyproportional to the bus effective bandwidth. The resulting picturequality is also proportional to the amount of motion in the videosequence. A video sequence of little motion can tolerate the loss ofmore video data, i.e., bus bandwidth, and visa-versa.

The present invention is implemented by: controlling what data isbuffered for bus transmission to the frame buffer; determining whichpixels are dropped when bus bandwidth is unavailable; tracking how manypixels are dropped, and their pixel offset in a given line of videodata; and determining when to resume buffering of pixel data bymonitoring bus bandwidth.

Decoded video data is received for bus transfer typically at a constantrate, for example, at 1 pixel every 74 nanoseconds. The pixel format isassumed to comprise 4:2:2 YCrCb. Therefore, every pixel pair willconsist of two luma (Y) pixels and one chroma pixel pair (Cr & Cb). Thisdata can be buffered directly into a first-in first-out (FIFO) videooutput buffer, or it may be scaled through a half horizontal reductionfilter, such as depicted in FIG. 1, to limit bandwidth before beingstored into the FIFO.

As noted, FIG. 1 depicts pixel data 10 being passed through a one-halfhorizontal resolution filter before being stored into the video outputbuffer (or FIFO buffer) 40. Specifically, pixel data of a current luma(Yn) and a next luma (Yn+1) is received at averaging logic 14 for 2:1filtering. Timing is achieved by buffering luma (Yn) at buffer 12.Similarly, chroma pixels Cn and Cn+2 are averaged together by logic 20for a 2:1 filtering. The chroma (Cn) pixel Cb and Cr are temporarilyheld at buffers 16 & 18, respectively, before being multiplexed intoaveraging logic 20, again to ensure timing with the chroma (Cn+2) pixel.By averaging two pixels together, the bandwidth for transmission overthe bus is effectively cut in half. Output from averaging logic 14 aretwo luma values which are buffered 22 for merging with the averagedchroma (Cr and Cb) pixels output from averaging logic 20. Chroma pixelCb is temporarily latched in buffer 24. The resultant compilationcomprises Y₁ Cb₂ Y₂ Cr₂ Y₃ Cb₄ Y₄ Cr₄, etc.

As shown in FIG. 1, the reduced bandwidth pixel data is multiplexed 26with pixel data 10 employing a half horizontal resolution--enable(HHR-EN) signal. This signal allows selection between the halfresolution or full resolution pixel data. Ordering of bytes isestablished at multiplexer 28 employing an "Endian" signal. Multiplexer28 establishes byte ordering within a 32 bit word. Sixteen bits areoutput to buffers 30 which comprise the staging to generate the 32 bitsof data to be output on bus 50. The 32 bits of data are temporarily heldin video output buffer (or FIFO) 40 as shown.

The problem addressed by this invention arises because pixel data entersbuffer 40 at a fixed rate while the bandwidth of bus 50 can vary. Asdata is saved into buffer 40, a bus resource request is sent by acontroller 60. Bus latency comprises a delay between transmission of therequest and granting of a bus resource for transmission of thecorresponding block or packet of video data from buffer 40. This latencycan be indeterminant in length and if too long, can cause overrunning ofthe buffer 40.

Buffer data is packetized for transmission onto the bus based onprogrammable settings. The packet sizes can be selected to be a specificbyte size or they may be based on the buffer threshold. When a packet isready for transmission, the bus is requested. When the bus request isgranted, the data is written to the programmed target address in aseries of burst cycles based on the packet size. Each packet will have astarting address (within a line of video data) which will be incrementedby the packet size. This will repeat until an entire video line istransmitted. At this point, the starting address of the first packet forthe next line is calculated in preparation for transmission of the nextvideo line. Each line will be transmitted in this manner until a wholefield or frame has been written. The start of the next field or framewill re-initialize the video packet starting address based on theprogrammed address settings.

When the bus bandwidth is less than the incoming video data rate somevideo data will be lost. Insufficient bus bandwidth may be due to otheractivity on the system which resulted in an increased latency from whenthe bus is requested until bus granting. When the bus latency is highenough, the buffer will overrun and video data must be dropped.Presented herein is a novel approach for determining what data is to bedropped.

Controller 60 in the video data transfer apparatus of FIG. 1 overseespacketizing of video data stored into video output buffer 40. This isaccomplished through write control logic 42 and read control logic 44.As video data is written into buffer 40, an input pointer 43 isincremented, while reading of data from buffer 40 increments an outputpointer 45. The difference between these pointers is a measure of thefullness of the buffer. As input, controller 60 receives pixel timingcontrols such as horizontal and vertical blanking signals, field ID, andvalid frame signals. From these signals, and the state of the input andoutput pointers, the controller controls packetizing of video data inthe buffer, requesting bus bandwidth for transmission of a packet, andoutputting of an address signal corresponding to packetized video dataoutput from the buffer to bus 50. In accordance with the presentinvention, controller 60 comprises the mechanism for trackingdiscontinuities in packetized video data output to the bus and ensuringthat the appropriate address is sent for each packet or block of videodata output as part of a video line.

FIG. 2 is a depiction of one embodiment of a video frame or field havinga plurality of horizontal video lines, each video line comprising aplurality of pixels. FIGS. 3a & 3b depict processing of video datastored into buffer 40 under "normal" conditions. The video data isrepresented in FIG. 3a as a horizontal video line which has a startingaddress and an ending address. Pixel location is represented as adisplacement from the starting address. In FIG. 3b, packetized videodata of FIG. 3a is shown to comprise packet N through packet N+7. Inthis embodiment, the packets are of equal size, and the packets containvideo data with increasing addresses within the horizontal video line.Packet N is transmitted after a predetermined amount of video data hasbeen stored into buffer 40.

In accordance with the present invention, upon detection of an overflowcondition within buffer 40, incoming pixel data to the buffer is droppeduntil a pending bus request is serviced and buffered video data isstarted to be read from the buffer. A next bus request is then sent outby the controller and the controller prepares, i.e. packetizes, allremaining video data in the buffer for transmission. Simultaneous withthis, the buffer begins to resume receiving incoming video data undernormal operation. The controller also recalculates the starting addressfor a new packet to contain resumed video data to account for the pixeldiscontinuity.

One example of this approach is depicted in FIGS. 4a & 4b wherein thehorizontal video line of FIG. 4a is assumed to have overrun video outputbuffer 40 (FIG. 1) at some point during processing of the pixel data inthe line. In FIG. 4b, packets N, N+1 and N+2 would essentially comprisethe same packet size as depicted in FIG. 3b. However, since overflow isassumed to have been detected while waiting to transmit packet N+2, thenext packet, i.e. packet N+3, encompasses all remaining data in thebuffer. This is desirable since the controller is able to maintainaddress continuity by emptying the remaining contents of the buffer. Thediscontinuity is representative of the dropped pixel data and theremaining packets N+4 through N+6 are assumed to comprise standardpacket sizes. Controller 60 (in accordance with the present invention)determines the starting address for packet N+4 based on the amount ofdata dropped during the discontinuity. Again, starting address for apacket of video data representative of pixels in a horizontal video lineis determined as an offset from the starting address of the horizontalvideo line.

The discontinuity in the video image sequence has a duration equal tothe latency from the buffer overrun to the time that the granting of thepending bus request for packet N+2 was received (plus some smalloverhead time). This elapsed time period is essentially random innature. The overrun may be due to bus contention during heavy systemactivity or it could be that the destination address has a resourceconflict. In any case, the destination frame buffer receives most of thevideo image data. The data that is not transmitted will be occupied bythe image data from the previous frame. By taking advantage of thetemporal redundancy of moving picture video, this "old" data should notbe perceived by the viewer. Thus, in accordance with the presentinvention, higher bus latency can be tolerated without producingperceptible video degradation.

FIG. 5 depicts a flowchart of video line processing through the videodata transfer apparatus of FIG. 1 under normal conditions. Afterenabling a channel 100 for the transmission of video data in the videoprocessing system, the transfer apparatus monitors received data forvertical blanking 102. Vertical blanking comprises a synchronizationsignal that is defined as the interval between frames when no video datais transmitted. At the start of a new frame or field, vertical blankingis no longer present and processing inquires whether horizontal blankingexists 104. The horizontal blanking interval comprises the blank timeperiod from the end of one horizontal video line to the start of thenext video line. If not in horizonal blanking, then video lineprocessing is started 106.

The starting address for the video line is calculated as the address forthat line within the frame buffer 108, and data packet processing 110 iscommenced, which includes buffer write control and buffer read controlas outlined in phantom. The read control and write control processingsoccur simultaneously. Beginning with the write control, processinginitially inquires whether valid pixel data is received 112. If pixeldata is not presently being captured, processing waits until the nextvalid pixel data. In one embodiment, pixel data may be written into thebuffer every 74 nanoseconds. if valid pixel data is received, processingdetermines whether the video output buffer is full 114. If "yes", thenoverflow processing 150 (FIG. 6) in accordance with the presentinvention is called. Otherwise, the pixel data is loaded into the bufferand the input pointer 43 (FIG. 1) is incremented 116. Processing thendetermines whether the received pixel data is at an end of the videoline 118. If "no", return is made to 110 for further data packetprocessing. Conversely, if a video line has just been completed,processing returns to inquiry 102 to determine whether vertical blankingis present.

As noted, buffer read control processing can occur simultaneously withthe above-noted buffer write control processing. Read control initiallyinquires whether a data packet is ready for transmission 120. Forexample, is a data packet of specified size ready to transmit, i.e., isthere enough data in the buffer to send out a packet? If "no", readcontrol processing waits until receipt of sufficient data. If "yes",then the packet address is determined and a bus request is sent toobtain sufficient bus bandwidth to transmit the data packet 124. Oncethe bus grant is received, data is read from the FIFO buffer in burstsuntil the entire packet is transmitted 126, and the output pointer isincremented with the reading of data from the buffer. After transmittingthe packet, processing determines whether an end of the video line hasbeen reached 118 and proceeds therefrom as discussed above.

FIG. 6 depicts one embodiment of overflow recovery processing inaccordance with the present invention. This processing begins withdetection of an overflow condition or overflow pending state 150. Upondetection of this state, the depicted buffer read and write controlsproceed simultaneously. The write control initially determines whethervalid pixel data has been received during the overflow pending state 152and if yes, processing drops the data 154. Inquiry is then made intowhether the overflow pending state is still valid 160, and if so,processing loops back to overflow pending state 150 and hence inquiry152 to await receipt of the next valid pixel data.

During overflow pending state, data is read from the buffer once thepending bus request is granted. This data is read and output in the formof a packet as described above. Read control processing determineswhether this data packet has been transmitted 156 and if no, the readcontrol processing waits for transmission of the packet. Once the packetin process of transfer is completed, the overflow pending state is resetor cleared, and an overflow in-process state is set 158. Once theoverflow in-process state is set, processing proceeds from inquiry 160into the overflow in-process routine 162 where buffer write control andread control processing can again occur simultaneously. Beginning withthe write control processing, processing waits until valid data isreceived 164. Upon data receipt, processing determines whether thebuffer is full 166 and if so, return is made to overflow pending state150 for further processing as described above. If there is room in thebuffer, then the pixel data is loaded into the buffer and the inputpointer is incremented 168. Processing then inquires whether theoverflow in-process state is still set 170, and since the overflowin-process state can only be reset pursuant to read control processing,return is made to overflow in-process state 162 to await the next pixeldata 164.

Read control processing begins with assignment of the remaining portionof the buffer to a next packet to be output onto the bus 172. The packetaddress for this packet is determined 174 to account for thediscontinuity in data in the video line. A request for bus bandwidth ismade 176 and upon granting, the video data remaining in the buffer priorto the discontinuity is read from the FIFO, the output pointer iscorrespondingly incremented, and the "in-process state" is reset 178.Upon resetting the in-process state, processing returns to the normalcondition processing of FIG. 5 at the point where overflow recoveryprocessing was called 151 (see FIG. 5).

FIGS. 7a, 7b & 7c depict bus bandwidth effects on video packettransmission for normal processing of data. In FIG. 7a, a horizontalvideo line is shown, FIG. 7b depicts transmission of data packets Nthrough N+7 where the bus bandwidth is greater than the pixel data ratecoming into the buffer, and FIG. 7c depicts buffer fullness. As shown inFIG. 7c, with transmission of each packet, data read from the bufferreduces the fullness of the buffer.

FIGS. 8a, 8b & 8c depict an overflow recovery processing state inaccordance with the present invention. These figures show how bufferallocation changes relative to pixel data rate coming in and the databandwidth available on the bus. FIG. 8a again shows a horizontal videoline and FIG. 8b depicts bus bandwidth relative to pixel data ratecoming into the buffer. In this case, the bus bandwidth is assumed to beless than the rate of pixel data into the buffer such that overflowconditions occur upon fullness of the buffer as shown in FIG. 8c. Theoverflow conditions result in data discontinuity between the data ofpacket N+1 and packet N+2, as well as between the data of packet N+3 andpacket N+4. In accordance with this invention, the controller determinesthe new starting address for packets N+2 and N+4 relative to start ofthe horizontal video line. FIGS. 8a-8e also depict an example whereinthe bandwidth is insufficient over a period of time for the pixel datarate into the buffer such that the processing switches multiple timesbetween the normal condition processing of FIG. 5 and the overflowrecovery processing of FIG. 6 as described above.

The present invention can be included in an article of manufacture(e.g., one or more computer program products) having, for instance,computer useable media. The media has embodied therein, for instance,computer readable program code means for providing and facilitating thecapabilities of the present invention. The article of manufacture can beincluded as part of a computer system or sold separately.

Presented herein is an approach for transmitting real-time video data ona non-real-time medium with minimal loss of perceptible picture quality.The video data transfer apparatus takes advantage of temporalredundancies between frames in the video system by dropping pixel dataat random spatial locations when insufficient bus bandwidth is availableand relying on the previously spatially located pixel data to replacethe lost data. The effective result is transmission of a video imagewith "holes" where data was not transmitted. These holes are againreplaced by the previous spatially located pixel data. Thus, inaccordance with the invention, the video processing system is able totolerate greater occurrence of insufficient bus bandwidth withoutdegrading perceptible picture quality. Processing in accordance withthis invention can be performed in place of or in addition toconventional techniques for reducing bandwidth of decompressed videodata.

While the invention has been described in detail herein in accordancewith certain preferred embodiments thereof, many modifications andchanges therein may be effected by those skilled in the art.Accordingly, it is intended by the appended claims to cover all suchmodifications and changes as fall within the true spirit and scope ofthe invention.

What is claimed is:
 1. A computer program product for processing a lineof video data for transmission across a bus, the line of video databeing temporarily written to a buffer, the buffer being coupled to thebus for reading of data in blocks from the buffer to the bus, saidcomputer program product comprising:(a) a computer usable medium havingcomputer readable program code means embodied in said medium for causinga selective reduction in bandwidth of the line of video data, saidcomputer program product having:(i) computer readable program code meansfor causing said computer to detect an overflow condition within thebuffer; (ii) computer readable program code means for causing saidcomputer to discard data from the line of video data being temporarilywritten to the buffer upon detecting said overflow condition; (iii)computer readable program code means for causing said computer totransmit a pending block of video data from the buffer upon granting ofa pending request for transmission of the pending block of video datafrom the buffer, said pending request being pending prior to saiddetecting (i), and upon beginning said transmitting, to discontinue saiddiscarding of data from the line of video data being temporarily writtento the buffer; and (iv) computer readable program code means for causingsaid computer to provide at least one next bus request for transmissionof at least one next block of video data from the buffer to the bus,said at least one next block of video data comprising all remainingvideo data in the buffer stored therein prior to said detecting of theoverflow condition.
 2. The computer program product of claim 1, furthercomprising computer readable program code means for causing saidcomputer to determine an address for a new block of video data writtento the buffer after said discontinuing (iii) discarding of data from theline of video data being written to the buffer.
 3. The computer programproduct of claim 2, further comprising computer readable program codemeans for causing said computer to provide a new bus request fortransmission of the new block of video data from the buffer across thebus.
 4. The computer program product of claim 2, wherein said computerreadable program code means for causing said computer to determine theaddress for the new block of video data comprises computer readableprogram code means for causing said computer to monitor said discarding(ii) to determine a discarded amount of data from said line of videodata and to use said discarded amount of data to determine the addressfor the new block of video data as an offset from a starting address ofthe line of video data.
 5. The computer program product of claim 1,further comprising computer readable program code means to cause saidcomputer to set an overflow pending state upon detecting of the overflowcondition and to reset said overflow pending state upon transmitting ofthe pending block of video data from the buffer to the bus.
 6. Thecomputer program product of claim 5, further comprising computerreadable program code means for causing the computer to set an overflowinprocess state upon resetting the overflow pending state, and to resetthe overflow in-process state upon transfer of the at least one nextblock of video data from the buffer to the bus subsequent to a grantingof the at least one next bus request.
 7. The computer program product ofclaim 5, further comprising computer readable program code means forcausing said computer to set said overflow pending state if a furtheroverflow condition is detected subsequent to beginning transmitting ofthe pending block of video data, and to repeat the computer processingof said computer readable program code means (i)-(iv).
 8. At least oneprogram storage device readable by a machine, tangibly embodying atleast one program of instructions executable by the machine to perform amethod of processing a line of video data for transmission across a bus,the line of video data being temporarily written to a buffer, the bufferbeing coupled to the bus for reading of data in blocks from the bufferto the bus, comprising:(a) detecting an overflow condition within thebuffer; (b) upon detecting said overflow condition, discarding data fromthe line of video data being temporarily written to the buffer; (c) upongranting of a pending request for transmission of a pending block ofvideo data from the buffer, transmitting the pending block of video datafrom the buffer to the bus, said pending request being pending prior tosaid detecting (a), and upon beginning said transmitting, discontinuingsaid discarding (b) of data from the line of video data beingtemporarily written to the buffer; and (d) providing at least one nextbus request for transmission of at least one next block of video datafrom the buffer to the bus, said at least one next block of video datacomprising all remaining video data in the buffer stored therein priorto said detecting (a) of the overflow condition.
 9. The at least oneprogram storage device of claim 8, further comprising determining anaddress for a new block of video data written to the buffer after saiddiscontinuing (c) of said discarding of data from the line of video databeing written to the buffer.
 10. The at least one program storage deviceof claim 9, further comprising providing a new bus request fortransmission of the new block of video data from the buffer.
 11. The atleast one program storage device of claim 9, wherein said determining anaddress comprises monitoring said discarding (b) to determine adiscarded amount of data from said line of video data and using saiddiscarded amount of data to determine the address for the new block ofvideo data as an offset from a starting address of the line of videodata.
 12. The at least one program storage device of claim 8, furthercomprising repeating steps (b)-(d) for each overflow condition detectedwithin the buffer.
 13. The at least one program storage device of claim8, further comprising setting an overflow pending state upon saiddetecting (a) of the overflow condition and resetting said overflowpending state upon transmitting (c) of the pending block of video datafrom the buffer to the bus.
 14. The at least one program storage deviceof claim 13, further comprising setting an overflow in-process stateupon resetting said overflow pending state, and resetting said overflowin-process state upon transfer of the at least one next block of videodata from the buffer to the bus subsequent to a granting of the at leastone next bus request of said providing (d).
 15. The at least one programstorage device of claim 13, further comprising setting said overflowpending state if a further overflow condition is detected subsequent tobeginning said transmitting (c) of the pending block of video data, andrepeating said steps (b)-(d).
 16. The at least one program storagedevice of claim 8, wherein said line of video data comprises a line of aframe or a field of video data, and further comprising repeating saidprocessing for each line of video data of said frame or field.
 17. Theat least one program storage device of claim 8, wherein said line ofvideo data comprises one line of a frame or a field of video data, saiddiscarding (b) creating gaps in said line of video data, and furthercomprising filling said gaps in said line of video data with video datain a corresponding position in a corresponding line of video data in aprevious frame or a previous field.